Keyboards come in a variety of types or formats (e.g., keyboards of different languages have different keys at the same key position on the keyboard template). The nature of keyboard operation makes such keyboard variability problematic. This arises from the fact that when one presses a key on a keyboard, the keyboard is not sending to the OS (Operating System) the character (e.g., ASCII (American Standard Code for Information Interchange)) representation of what was pressed. Instead, the keyboard itself is sending Scan Code to the OS, which can be one or more bytes, and represents a location on the keyboard. It does not necessarily represent the character equivalent (e.g., ASCII).
For example, if one presses the letter “Z” on a US keyboard (located on the lower left portion of the keyboard), or on a French keyboard or on a German keyboard, these keys are located at different places on each keyboard. Thus, when one presses that letter “Z” on those three keyboard types, one actually gets three different Scan Codes. The keyboard architecture itself does not indicate what type of keyboard it is (e.g. English, French, German, etc.). This variability in actual keys at a particular positions (e.g. “Z” located at different positions on different keyboards) gives rise to various problems (for example, there is no standardized way to handle these differences at the pre-boot level, discussed below).
In a pre-boot environment (i.e. a stage where the OS has not yet booted) there is no formal way to handle the multiple languages possible through the keyboard and display device. As stated, POST/BIOS (“Power-on Self-test”/“Basic Input/Output System”) handles key-inputs as Scan Code, independent from the ASCII/uni-code. This comes from the PS/2 architecture to achieve flexibility to support multiple languages only in the OS environment and in order to make the Personal Computer (PC) hardware simpler. The numbers 0-9 and beeps for user interface are utilized. For example, two beeps show a POST error with a number (e.g. “163” shows CMOS checksum error). By default, English (United States) is set in POST/BIOS. There is no formal way to inform a keyboard type (e.g. ASCII). Normally, the OS equates a Scan Code with key characters (i.e. the OS translates the keys using some type of mapping).
Currently in the BIOS environment, when one presses a key, the BIOS has no indication of what character was pressed, merely the location of the pressed key. In other words, the BIOS simply ascertains the location of the key that was pressed based on the given Scan Code. For instance, when one types a password, BIOS cannot discern whether “A” or “B” or “C”, etc., was pressed; it is only discernable that a particular location was pressed (through the corresponding Scan Code). This is why BIOS passwords are normally lower case and restricted, because this area of the keyboard is normally standardized for characters (e.g. shift key for upper case is not acceptable because that key can move around to different locations in different types of keyboards). For example, BIOS passwords are commonly restricted to alphanumeric keys only. Thus, some passwords acceptable under the OS environment are unacceptable in the pre-boot environment. Thus, in BIOS, only the location of the particular key is indicated by the Scan Code, not the actual key occupying that position and this leads to restrictions on what may be available keys for BIOS passwords—they are restricted to constant keys. This in turn leads to password variability difficulties (e.g. a user's OS password may be unacceptable in the pre-boot environment, necessitating creation and memorization of multiple passwords).
Pre-boot is becoming a more critical environment for client PC manageability, as it is secure enough to handle vital data and has the rich networking capability for secret exchanges made in a secure way. Intel iAMT is one such example. Therefore, some level of user interface is required until rich GUI (Graphical User Interface) is available by booting the normal OS or small specific purpose OS with consistent keyboard and character display.
Less preferable methods not implemented which attempt to handle such problems include the following. One may install multiple character sets in the system non-volatile random access memory (NVRAM) and have a user choose the appropriate language. For example, one of the THINKCENTRE series of computers sold by Lenovo (US) Inc. of Morrisville, N.C., may have multiple pre-installed languages in BIOS-FLASH ROM (Flash Erasable Programmable Read-Only Memory), whereby the user chooses the appropriate language. However, the number of languages will be limited based upon storage size and must be chosen manually. Moreover, it can be burdensome to ask a user what kind of keyboard is being used. One may also boot a small OS supporting multiple languages. The planar (motherboard) in this context would need to have storage space for this OS or a method would be required to download this OS image from a HDD (Hard disk), CD-ROM (Compact Disk-Read Only Memory), or a network. Moreover, this would require a capability to prepare the OS images for each language, or the capability to support multiple language within single OS image.
Therefore, a need has arisen in connection with the above-described shortcomings in order to provide multi-language support in a pre-boot environment and solve the various problems associated therewith.